The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Unicast Versus Multicast Communication
Multicast refers to a technique for communicating between a single sender and multiple receivers over a network. Multicast can be used in a private network environment, such as a corporate LAN, or in a public network environment, such as the Internet wide area networks. For example, multicast is used on the Mbone (sometimes referred to as the Multicast Internet), a specific high-bandwidth subset of the Internet. The MBone includes known network elements such as routers and servers that are equipped to handle multicast protocols. Furthermore, multicast is one of the packet types supported in the Internet Protocol Version 6 (IPv6).
In contrast to multicast, unicast refers to a technique for communicating between a single sender and one or more receivers, point-to-point, over a network. Like multicast, unicast can also be used for high-bandwidth communications, such as video and sound programming and voice and video conferencing. However, unicast can be implemented using general-purpose network components and does not rely on special-purpose network elements, such as servers and intermediate gateways, as with multicast. In addition, multicast has several deployment issues with network service providers, such as accounting challenges and bandwidth provisioning. Hence, unicast is often a more appropriate and desired mechanism for communications over a public network than is multicast.
Secure Network Communication Protocol
Communications protocols exist that facilitate secure communication over a network. One such commonly used protocol is IPsec. The Security Architecture for the Internet Protocol and related protocols such as IKE and ISAKMP (collectively referred to herein as IPsec) provide a standards-based method of providing privacy, integrity, and authenticity to information transferred point-to-point among peers across IP networks, such as the public Internet wide area networks and private local area networks. Key management and security associations are negotiated with the Internet Key Exchange (IKE) protocol. Each security association (SA) is a set of IPsec parameters that have been negotiated between two devices, and which govern the security of network traffic between the devices. SAs are unidirectional, in that one SA is established for traffic from a first endpoint to a second endpoint, and another SA is established for traffic from the second endpoint to the first endpoint.
Security associations are typically stored at each network device that participates in secure communication using a network security protocol such as IPsec. For example, in the context of IPsec, security associations for secure connections negotiated by a given network device are stored in a Security Association Database (SAD) within the device. The SAs are uniquely identified by a receiver in an associated SAD by a combination of a Security Parameter Index (SPI), a Destination IP Address, and a relevant security protocol (such as AH or ESP).
Conventionally, a SPI is established by the receiver and sent back to the sender peer, as part of the IKE negotiation process between the sender and receiver. Subsequently, this SPI is sent in the ESP header of packets sent by the sender to the receiver, to facilitate identifying and locating the appropriate SA in the SAD of the receiver. This process is designed to avoid SPI conflicts at the receiver, based on the presumption that a receiver that establishes SPIs for its database will not establish identical SPIs for different independent SAs.
Some network applications and processes, such as encrypted voice conferences, operate efficiently in a hub-and-spoke arrangement. In such an arrangement, all traffic from each conference participant, or peer, traverses first to the hub and then back out to the other participants. In the voice conference context, the hub is a conference server that functions to mix all of the audio streams received from the conference participants (spokes) and to transmit the resultant audio stream to all the participants. With such an application, it is efficient to have multiple peers use a single common security policy. For example, a policy may be negotiated by the conference initiator and the conferencing server, and dictated or applied to each subsequent peer-to-peer connection between the conferencing server and the other conference participants.
In an environment in which a common security policy is used by multiple peers, such as with an encrypted voice conference, SAs that represent the common security policy are negotiated by the hub and each respective peer. For example, an IKE process is used to negotiate the SAs and associated keys. However, as part of the SA negotiation processes between the hub and the respective peers, different encryption/decryption key pairs are typically established for each hub-to-peer connection. Consequently, the hub is required to separately encrypt each packet stream that is sent out to each respective peer, which, in total, is a computationally expensive and inefficient process.
One approach to the foregoing scenario is use of the Group Domain of Interpretation (GDOI), an ISAMKP Domain of Interpretation for group key management. The GDOI manages group security associations, which are used by IPsec and potentially other security protocols running at the IP or application layers. However, GDOI is not applicable to unicast applications and applies only to secure multicast applications, of which practical disadvantages are described above.
Based on the foregoing, there is a clear need for a technique for secure unicast group communication. There is a more specific need for a technique for using a common key for all peers participating in a unicast group communication.